まだまだ続く情報漏えい　1社の侵入が380社に波及、開発者・インフラ担当・利用者が今やること

前回の記事では、個人情報保護委員会が公表した「半年で延べ約2億6000万人」という数字と、10月に相次いだ大規模漏えいを整理しました。あれから1週間ほどですが、勢いはまったく止まっていません。むしろ11月に入って、1社への侵入が数百社の漏えいに広がるという、一段深刻な形が目立つようになりました。

民間のインシデント集計サイトによると、11月1日から4日までのわずか4日間に初めて公表された事案は62件にのぼります。今回は、10月末から11月初めにかけて明らかになった主な事例を整理したうえで、「結局、何をすればいいのか」を開発者・インフラ担当・利用者の3つの立場に分けて、改めてまとめ直します。

最大の焦点：メール配信「アララメッセージ」への侵入

この1週間で最も影響が大きかったのが、ペイクラウドホールディングス傘下のアララが提供するメール配信サービス「アララメッセージ」への不正アクセスです。11月2日の第2報で明らかになった内容は次のとおりです。

規模：持ち出されたおそれのあるメールアドレスは約7700万件。影響を受ける契約企業は最大約380社（重複を含み、精査中）
手口：Webサーバの脆弱性に加え、システム環境の問題も関係。侵入した1台を足がかりに、10月28日〜31日にかけて契約企業の環境にあるサーバ97台へ横展開し、データベースの中身を持ち出した
共用環境：10月27日〜28日に、61社分のメールアドレス約338万件が持ち出された
なりすましメール：10月28日〜30日に、乗っ取られた環境からカード会社を装うメールが最大約713万通送られた（送信元「news@arara.com」、件名「利用内容確認のご依頼」など）

アララは10月31日から全サービスを停止しています。その結果、メルマガを委託していた企業が次々と「委託先からの漏えい」を公表することになりました。主なものは下表のとおりです。

公表日	企業・サービス	規模	主な対象情報
11/2	ビックカメラ・コジマ・ソフマップ	3社合計約1490万件	メールマガジン登録者のメールアドレスなど
11/3	アソビュー	1582万1184件	メールアドレス、氏名、会員ID、最終ログイン日、チケット購入履歴など
11/4	ワークマン	最大約145万件	メールアドレス
11/5	IIJmio	98万3458件	メールアドレス（解約者を含む）
11/2〜4	TKC、ダスキン、住友不動産、モスなど	数百〜数百万件	メールアドレスなど

注目したいのは、漏えいの公表とフィッシングがほぼ同時に起きた点です。攻撃者は盗んだアドレスに、本物の配信基盤を使って偽メールを送りつけました。正規のサービスから送られているため、送信ドメイン認証で弾けません。なお10月には同じメール配信業界でユミルリンクやラクスライトクラウドも被害を受けており、メール配信基盤が集中的に狙われていることがうかがえます。

そのほかの主な事例（10月31日〜11月5日）

公表日	組織・サービス	規模	主な対象情報	経路・原因
10/31	クラブツーリズム	約432万件	氏名、国籍、生年月日、住所、電話番号、緊急連絡先	ネット予約システムへの不正アクセス（サイト停止中）
11/2	アイスタイル「@cosme」	約300万人	氏名、住所、電話番号、生年月日、肌質・髪質など	不正アクセス（手口は非公表）
11/2	ノジマオンライン	約700万件	氏名、住所、電話番号、生年月日、暗号化パスワードなど	会員管理システムへの不正アクセス
11/3	セブン‐イレブン「7NOW」／出前館	16万件超／約800件	注文者名、一部は住所・電話番号・注文内容	配送委託先CBcloud「ピックゴー」の不具合を悪用
11/3	デニーズ公式アプリ	調査中	会員コード、メール、生年月日など	旧アプリからの移行処理で認証情報を不正に作成された
11/4	ApplyNow（採用関連サービス）	39万6920人	応募者情報、一部はマイナンバー・口座情報・在留カード番号	公表済みだったツールの脆弱性を放置

このほか、総務省、横浜市・大阪市・川崎市などの自治体、北陸電力、琉球銀行、クレディセゾン、Zaifなど、業種や官民を問わず公表が続いています（自治体の多くはアララなど委託先経由の影響とみられます）。

今回の事例が教えてくれること

「1台破られたら全部」の構成になっていないか

アララの事案では、1台への侵入が97台・数百社に広がりました。前回紹介したIDCFクラウドでも、ポータルの認証システムから仮想化基盤の管理者権限まで奪われています。マルチテナント型のサービスでは、テナントの間の壁と、サーバ同士の横移動を止める仕組みがなければ、被害は契約企業の数だけ掛け算になります。

「一時的な処理」や「社内ツール」が穴になる

デニーズでは、旧アプリから新アプリへ移るための処理が悪用され、第三者が認証情報を作れてしまいました。ApplyNowでは、社内のデータ分析ツールの脆弱性が、提供元が公表していたのに把握されず放置されていました。しかもそのツールは接続元が制限されておらず、個人情報を直接参照でき、契約が終わったデータも消されていませんでした。どちらも本番のメイン機能ではなく、「脇にある仕組み」が入口になっています。

「操作記録がない」と被害者を特定できない

デニーズは、個人情報を取得する処理が実行された記録は確認したものの、それが第三者の操作か本人の操作かを区別できず、対象人数を特定できていません。前回のグッドスマイルカンパニーと同じ構図です。ログが不十分だと、企業は「全員が対象かもしれない」と発表するしかなくなります。

結局、何をすればいいのか：立場別の対策

前回の記事でも対策を挙げましたが、改めて「誰が・何を」担うかで整理します。役割が分かれていない小さな組織では、一人が複数の立場を兼ねることになるので、自分に関係する列を全部見てください。

立場	まずやること（今週中）	続けること
開発者	移行用・管理用・内部用のAPIを洗い出し、認可と記録を確認する	持つデータを減らす設計、依存ライブラリの更新、操作ログの設計
インフラ担当	外部公開資産と委託先・SaaSの一覧化、管理系への多要素認証と接続元制限	パッチの即時適用体制、横移動の遮断、ログの外部保管と監視
利用者	メール内リンクからログインしない、パスワードの使い回しをやめる	パスキー・多要素認証、使わないサービスの整理、明細の確認

開発者がやること

1. 「一時的な処理」こそ、本番と同じ厳しさで作る

データ移行、アカウント引き継ぎ、キャンペーン用のAPI、障害対応のための裏口。こうした「期間限定」の処理は、テストもレビューも薄くなりがちです。デニーズのような移行処理なら、少なくとも次の点を確認してください。

旧環境での本人確認（旧パスワードや旧端末に紐づくトークンなど）なしに、新しい認証情報を発行できないか
引き継ぎコードは推測できない長さか、1回きり・短時間で失効するか、試行回数に上限があるか
移行期間が終わったら、エンドポイントごと確実に止める日付が決まっているか

// NG：会員コードさえ分かれば新アプリの認証情報が発行される
POST /migrate  { memberCode }
  → issueNewCredential(memberCode)

// OK：旧アプリで本人が発行した使い捨てコードを検証してから発行
POST /migrate  { memberCode, oneTimeCode }
  → code = findValidCode(memberCode, oneTimeCode)   // 10分で失効・1回限り
  → if (!code || tooManyAttempts(memberCode)) return 403
  → markUsed(code)
  → audit.log("migrate", memberCode, clientIp, deviceId)   // 誰が実行したか残す
  → issueNewCredential(memberCode)

2. 「誰が・何を取得したか」を後から追えるようにする

個人情報を返す処理には、実行者（ユーザーID、APIキー、管理者アカウント）、接続元、対象件数を必ず記録します。本人の操作か第三者の操作かを区別できれば、漏えいの範囲を絞り込め、通知や補償の負担も大きく変わります。アプリのログとは別に、改ざんされにくい監査ログとして残すのが理想です。

3. 「持たない」「すぐ消す」をコードに組み込む

退会・解約・契約終了のタイミングで、保存義務のない項目を削除または匿名化するバッチを実装する（IIJmioやApplyNowでは解約者・契約終了後の情報も対象になった）
メール配信などの外部サービスには、配信に必要な最小限の項目だけを渡す。最終ログイン日や購入履歴まで渡していないか見直す
分析用・社内ツール用のデータは、個人を特定できる項目をマスキングしたコピーを使う

4. マルチテナントなら、テナントの壁をアプリでも作る

SaaSを作っている側は、すべてのクエリにテナントIDの条件が付いているかを、レビュー任せにせず仕組みで担保します。データベースの行レベルセキュリティ（PostgreSQLのRow Level Securityなど）や、テナントごとの暗号鍵の分離を使えば、1つの穴から全顧客分を抜かれる事態を防ぎやすくなります。

5. 依存関係と脆弱性情報を自動で突き合わせる

ApplyNowの原因は「公表済みの脆弱性に気づかなかった」ことでした。人の目で追いかけるのは限界があります。SBOM（ソフトウェア部品表）を作り、Dependabotなどの依存関係チェックや脆弱性スキャンをCIに組み込んで、「知らなかった」をなくしましょう。本番アプリだけでなく、社内ツールやコンテナイメージも対象に含めるのがポイントです。

インフラ担当がやること

1. 外部から見えるものを全部リストにする

Webサーバ、管理画面、API、VPN、そしてApplyNowで穴になったような社内向けのつもりのツールまで含めて、インターネットから到達できるものを一覧にします。自社のIPアドレスやドメインを外部から定期的にスキャンし、知らないうちに公開されているものがないか確認すると確実です。

2. 管理系は「どこからでも入れる」をやめる

管理画面、データベース、分析ツール、クラウドの管理コンソールは、VPNや特定のIPアドレスからしか接続できないようにする
管理者・保守アカウントには多要素認証を必須にする。可能ならパスキーやハードウェアキーなど、フィッシングに強い方式にする
委託先の保守用アカウントは作業時だけ有効にし、共有アカウントは廃止する

3. 横に広がらない構成にする

アララの事案の核心は、1台から97台へ広がったことです。侵入を前提に、次のような「区切り」を入れておきます。

サーバ間の通信は、必要な組み合わせだけを許可する（セキュリティグループやファイアウォールを「全部許可」にしない）
テナントや顧客ごとに、ネットワークや認証情報を分ける。全サーバで同じSSH鍵や同じDBパスワードを使い回さない
サーバからインターネットへの外向き通信を制限する。大量のデータを外へ持ち出す通信は、ここで止めたり検知したりできる
認証情報はシークレット管理サービスに置き、短い有効期限で自動更新する

4. パッチは「月1回」ではなく「出たら当てる」

AIによって脆弱性の発見から攻撃までの時間が短くなっています。悪用が確認された脆弱性（米CISAのKEVカタログに載ったものなど）は、定期メンテナンスを待たずに適用する運用ルールを決めておきましょう。すぐに当てられない場合は、公開を一時停止する判断も選択肢に含めておきます。

5. 委託先・SaaSを「自社の攻撃面」として管理する

メール配信、配送、勤怠、採用など、個人情報を預けている外部サービスを一覧にし、それぞれ「何を渡しているか」「止めたらどうなるか」「事故時に誰から連絡が来るか」を整理します。アソビューがアララの報告を受けた当日に配信を止め、管理画面のパスワードやAPIキーを無効化できたのは、こうした整理があってこそです。

連携に使っているAPIキーや管理画面のパスワードの一覧と、すぐに無効化する手順を用意する
契約時だけでなく定期的に委託先の対策状況を確認し、事故時の報告期限と、契約終了後のデータ削除を契約に入れる
自社ドメインで配信している場合は、SPF・DKIM・DMARCを正しく設定し、なりすましメールを受信側で弾けるようにする

6. ログを残し、外へ逃がし、見る

ApplyNowでは侵入から検知まで約1か月かかり、検知のきっかけはツールが停止したことでした。サーバにもEDRを入れ、大量のデータ取得や深夜の管理者ログイン、外向きの大きな通信にアラートを設定します。ログは攻撃者に消されない別の場所へ送り、侵入初期までさかのぼれる期間を保存しておきましょう。

利用者がやること

ここまでの規模になると、「自分のメールアドレスはどこかで漏れている」と考えて行動したほうが安全です。やることは多くありません。

1. メールやSMSのリンクからログインしない

アララの件では、本物の配信サービスから「利用内容確認のご依頼」といったカード会社を装うメールが送られました。差出人や見た目で本物かどうかを判断するのは、もう難しくなっています。

ログインや確認は、公式アプリか、自分で登録したブックマークからだけ行う
「利用確認」「お詫び」「補償金」「パスワード再設定」をうたうメールのリンクは開かない
万一カード情報を入力してしまったら、すぐにカード会社へ連絡する
ただし、正規のメール受信設定まで解除する必要はない（IIJmioは、家族割引の案内メールを解除すると割引も外れると注意を促している）

2. パスワードを使い回さず、パスキー・多要素認証に切り替える

ノジマのように暗号化されたパスワードが漏れた事例もあります。同じパスワードを使い回していると、ほかのサービスまで芋づる式に乗っ取られます。パスワードマネージャーでサービスごとに別のパスワードにし、パスキーや多要素認証が使えるところは設定しておきましょう。

3. 使っていないサービスを整理する

解約済みのIIJmio利用者や、退会済みの会員も漏えいの対象になっています。退会しても情報がすぐ消えるとは限りませんが、持たれている情報が少ないほど被害は小さくなります。使っていないサービスは、任意の登録情報を消してから退会し、メールマガジンは不要なものから配信停止しておきましょう。

4. 漏れた情報に応じて動く

漏れた情報	やること
メールアドレス・電話番号・住所	突然届くメールやSMSは詐欺と考えて削除。電話で個人情報を答えない
ID・パスワード	該当サービスと、同じパスワードを使っている全サービスで変更
クレジットカード情報	カード会社に連絡して再発行を相談。しばらく明細を確認
マイナンバー・口座・本人確認書類	口座の入出金を確認し、信用情報機関（JICC、CIC、KSC）への本人申告を検討

情報の種類ごとの詳しい対処は、IPA（情報処理推進機構）がまとめたページも参考になります。

まとめ

11月に入って見えてきたのは、攻撃者が多くの企業のデータが集まる場所を狙っているという構図です。メール配信、配送、クラウド基盤といった共通の仕組みが1つ破られれば、数百社の顧客情報が一度に漏れ、しかもその基盤そのものがフィッシングの発射台になります。

だからこそ、対策も「自社のメイン機能を守る」だけでは足りません。開発者は移行処理や社内ツールといった脇道を本番と同じ厳しさで作り、インフラ担当は横に広がらない構成と委託先の管理を整え、利用者はリンクを踏まずパスワードを使い回さない。地味な基本の積み重ねが、今いちばん効く対策です。

本記事は、各社の発表、ITmedia NEWS・INTERNET Watchなどの報道（2026年11月5日時点の情報）をもとに整理したものです。件数や原因は各社の調査の進展により変わる可能性があります。特にアララの事案は影響企業・件数とも精査中のため、対象サービスを利用している方は各社の公式発表をご確認ください。コード例は説明用の一般的な例です。